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Les 


Introduction 


The purpose of this document is to describe coexistence between 
version 2 of the Internet-standard Network Management Framework [1- 
6], termed the SNMP version 2 framework (SNMPv2), and the original 
Internet-standard Network Management Framework (SNMPv1), which 
consists of these three documents: 


STD 16, RFC 1155 [7] which defines the Structure of Management 
Information (SMI), the mechanisms used for describing and naming 
objects for the purpose of management. 


STD 16, RFC 1212 [8] which defines a more concise description 
mechanism, which is wholly consistent with the SMI. 


STD 15, RFC 1157 [9] which defines the Simple Network Management 
Protocol (SNMP), the protocol used for network access to managed 
objects. 


Management Information 


The SNMPv2 approach towards describing collections of managed objects 
is nearly a proper superset of the approach defined in the Internet- 
standard Network Management Framework. For example, both approaches 
use ASN.1 [10] as the basis for a formal descriptive notation. 
Indeed, one might note that the SNMPv2 approach largely codifies the 
existing practice for defining MIB modules, based on extensive 
experience with the current framework. 


The SNMPv2 documents which deal with information modules are: 


Structure of Management Information for SNMPv2 [1], which defines 
concise notations for describing information modules, managed 
objects and notifications; 


Textual Conventions for SNMPv2 [2], which defines a concise 
notation for describing textual conventions, and also defines some 
initial conventions; and, 


Conformance Statements for SNMPv2 [3], which defines concise 
notation for describing compliance and capabilities statements. 


The following sections consider the three areas: MIB modules, 
compliance statements, and capabilities statements. 


MIB modules defined using the current framework may continue to be 
used with the SNMPv2 protocol. However, for the MIB modules to 
conform to the SNMPv2 framework, the following changes are required: 


SNMPv2 Working Group Standards Track [Page 2] 


RFC 1908 Coexistence between SNMPvl and SNMPv2 January 1996 


2.1. Object Definitions 


In general, conversion of a MIB module does not require the 
deprecation of the objects contained therein. Only if the semantics 
of an object truly changes should deprecation be performed. 


(1) The IMPORTS statement must reference SNMPv2-SMI, instead of 
RFC1155-SMI and RFC-1212. 


(2) The MODULE-IDENTITY macro must be invoked immediately after any 
IMPORTs statement. 


(3) For any descriptor which contains the hyphen character, the hyphen 
character is removed. 


(4) For any label for a named-number enumeration which contains the 
hyphen character, the hyphen character is removed. 


(5) For any object with an integer-valued SYNTAX clause, in which the 
corresponding INTEGER does not have a range restriction (i.e., the 
INTEGER has neither a defined set of named-number enumerations nor 
an assignment of lower- and upper-bounds on its value), the object 
must have the value of its SYNTAX clause changed to Integer32. 


(6) For any object with a SYNTAX clause value of an enumerated INTEGER, 
the hyphen character is removed from any named-number labels which 
contain the hyphen character. 


(7) For any object with a SYNTAX clause value of Counter, the object 
must have the value of its SYNTAX clause changed to Counter32. 


(8) For any object with a SYNTAX clause value of Gauge, the object must 
have the value of its SYNTAX clause changed to Gauge32. 


(9) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS 
clause. The value of the MAX-ACCESS clause is the same as that of 
the ACCESS clause unless some other value makes "protocol sense" as 


the maximal level of access for the object. In particular, object 
types for which instances can be explicitly created by a protocol 
set operation, will have a MAX-ACCESS clause of "read-create". If 


the value of the ACCESS clause is "write-only", then the value of 
the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause 
notes that reading this object will result implementation-specific 
results. 


(10) For all objects, if the value of the STATUS clause is "mandatory", 
the value must be replaced with "current". 
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(15) 


For all objects, if the value of the STATUS clause is "optional", 
the value must be replaced with "obsolete". 


For any object not containing a DESCRIPTION clause, the object must 
have a DESCRIPTION clause defined. 


For any object corresponding to a conceptual row which does not 
have an INDEX clause, the object must have either an INDEX clause 
or an AUGMENTS clause defined. 


For any object with an INDEX clause that references an object with 
a syntax of NetworkAddress, the value of the STATUS clause of both 
objects is changed to "obsolete". 


For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 
value which is expressed as a collection of sub-identifiers, change 
the value to reference a single ASN.1 identifier. 


Other changes are desirable, but not necessary: 


(1) 


Creation and deletion of conceptual rows is inconsistent using the 
current framework. The SNMPv2 framework corrects this. As such, 
if the MIB module undergoes review early in its lifetime, and it 
contains conceptual tables which allow creation and deletion of 
conceptual rows, then it may be worthwhile to deprecate the objects 
relating to those tables and replace them with objects defined 
using the new approach. 


For any object with a string-valued SYNTAX clause, in which the 
corresponding OCTET STRING does not have a size restriction (i.e., 
the OCTET STRING has no assignment of lower- and upper-bounds on 
its length), one might consider defining the bounds for the size of 
the object. 


For all textual conventions informally defined in the MIB module, 
one might consider redefining those conventions using the TEXTUAL- 
CONVENTION macro. Such a change would not necessitate deprecating 
objects previously defined using an informal textual convention. 


For any object which represents a measurement in some kind of 
units, one might consider adding a UNITS clause to the definition 
of that object. 


For any conceptual row which is an extension of another conceptual 
row, i.e., for which subordinate columnar objects both exist and 

are identified via the same semantics as the other conceptual row, 
one might consider using an AUGMENTS clause in place of the INDEX 
clause for the object corresponding to the conceptual row which is 


SNMPv2 Working Group Standards Track [Page 4] 


RFC 1908 Coexistence between SNMPvl and SNMPv2 January 1996 


an extension. 
Finally, when encountering common errors in SNMPvl MIB modules: 


(1) For any non-columnar object that is instanced as if it were 
immediately subordinate to a conceptual row, the value of the 
STATUS clause of that object is changed to "obsolete". 


(2) For any conceptual row object that is not contained immediately 
subordinate to a conceptual table, the value of the STATUS clause 
of that object (and all subordinate objects) is changed to 
"obsolete". 


2.2. Trap Definitions 


If a MIB module is changed to conform to the SNMPv2 framework, then 
each occurrence of the TRAP-TYPE macro must be changed to a 
corresponding invocation of the NOTIFICATION-TYPE macro: 


(1) The IMPORTS statement must not reference RFC-1215. 

(2) The ENTERPRISES clause must be removed. 

(3) The VARIABLES clause must be renamed to the OBJECTS clause. 
(4) The STATUS clause must be added. 


(5) The value of an invocation of the NOTIFICATION-TYPE macro is an 
OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly. 
Specifically, if the value of the ENTERPRISE clause is not ’snmp’ 
then the value of the invocation is the value of the ENTERPRISE 
clause extended with two sub-identifiers, the first of which has 
the value 0, and the second has the value of the invocation of the 
TRAP-TYPE. 


2.3. Compliance Statements 


For those information modules which are "standard", a corresponding 
invocation of the MODULE-COMPLIANCE macro must be included within the 
information module (or in a companion information module), and any 
commentary text in the information module which relates to compliance 
must be removed. Typically this editing can occur when the 
information module undergoes review. 
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2.4. Capabilities Statements 


In the current framework, the informational document [11] uses the 
MODULE-CONFORMANCE macro to describe an agent’s capabilities with 
respect to one or more MIB modules. Converting such a description 
for use with the SNMPv2 framework requires these changes: 


(1) Use the macro name AGENT-CAPABILITIES instead of MODULE- 
CONFORMANCE. 


(2) The STATUS clause must be added. 


(3) For all occurrences of the CREATION-REQUIRES clause, note the 
slight change in semantics, and omit this clause if appropriate. 


In order to ease the coexistence between SNMPvl and SNMPv2, object 
groups defined in an SNMPvl MIB module may be referenced by the 
INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: 
upon encountering a reference to an OBJECT IDENTIFIER subtree defined 
in an SNMPv1 MIB module, all leaf objects which are subordinate to 
the subtree and have a STATUS clause value of mandatory are deemed to 
be INCLUDEd. (Note that this method is ambiguous when different 
revisions of a SNMPvl MIB have different sets of mandatory objects 
under the same subtree; in such cases, the only solution is to 
rewrite the MIB using the SNMPv2 SMI in order to define the object 
groups unambiguously.) 


3. Protocol Operations 
The SNMPv2 documents which deal with protocol operations are: 


Protocol Operations for SNMPv2 [4], which defines the syntax and 
semantics of the operations conveyed by the protocol; and, 


Transport Mappings for SNMPv2 [5], which defines how the protocol 
operations are carried over different transport services. 


The following section considers two areas: the proxy behavior 
between a SNMPv2 entity and a SNMPvl agent; and, the behavior of 
"bi-lingual" protocol entities acting in a manager role. 

3.1. Proxy Agent Behavior 
To achieve coexistence at the protocol-level, a proxy mechanism may 


be used. A SNMPv2 entity acting in an agent role may be implemented 
and configured to act in the role of a proxy agent. 
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(1) 


SNMPv2 -> SNMPv1 


When converting requests from a SNMPv2 entity acting in a manager 
role into requests sent to a SNMPvl entity acting in an agent role: 


(1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is 


received, then it is passed unaltered by the proxy agent. 


(2) If a GetBulkRequest-PDU is received, the proxy agent sets the non- 


repeaters and max-repetitions fields to zero, and sets the tag of 
the PDU to GetNextRequest-PDU. 


SNMPv1 -> SNMPv2 


When converting responses received from a SNMPv1 entity acting in an 
agent role into responses sent to a SNMPv2 entity acting in a manager 
role: 


If a GetResponse-PDU is received, then it is passed unaltered by 
the proxy agent. Note that even though a SNMPv2 entity will never 
generate a Response-PDU with a error-status field having a value of 
‘noSuchName’, ‘badValue’, or ‘readOnly’, the proxy agent must not 
change this field. This allows the SNMPv2 entity acting ina 
manager role to interpret the response correctly. 


If a GetResponse-PDU is received with an error-status field having 
a value of ‘tooBig’, the proxy agent will remove the contents of 
the variable-bindings field before propagating the response. Note 
that even though a SNMPv2 entity will never generate a ‘tooBig’ in 
response to a GetBulkRequest-PDU, the proxy agent must propagate 
such a response. 


If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap- 
PDU. This is done by prepending onto the variable-bindings field 


two new bindings: sysUpTime.0 [6], which takes its value from the 
timestamp field of the Trap-PDU; and, snmpTrapOID.0O [6], which is 
calculated thusly: if the value of generic-trap field is 


“enterpriseSpecific', then the value used is the concatenation of 
the enterprise field from the Trap-PDU with two additional sub- 
identifiers, ‘0’, and the value of the specific-trap field; 
otherwise, the value of the corresponding trap defined in [6] is 
used. (For example, if the value of the generic-trap field is 
‘coldStart’, then the coldStart trap [6] is used.) Then, one new 
binding is appended onto the variable-bindings field: 
snmpTrapEnterprise.0 [6], which takes its value from the enterprise 
field of the Trap-PDU. The destinations for the SNMPv2-Trap-PDU 
are determined in an implementation-dependent fashion by the proxy 
agent. 
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3.2. Bi-lingual Manager Behavior 


To achieve coexistence at the protocol-level, a protocol entity 
acting in a manager role might support both SNMPvl and SNMPv2. When 
a management application needs to contact a protocol entity acting in 
an agent role, the entity acting in a manager role consults a local 
database to select the correct management protocol to use. 


In order to provide transparency to management applications, the 
entity acting in a manager role must map operations as if it were 
acting as a proxy agent. 


4. Security Considerations 
Security issues are not discussed in this memo. 
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